MASSACHUSETTS INSTITUTE OF TECHNOLOGY 
A. I. LAB 



Artificial Intelligence 

Nemo No. 210 December 1970 



A USER'S GUIDE TO THE A. I* GROUP LISCOM LISP COMPILER* 

INTERIM REPORT 



Jeffrey Pt Golden 



Work reported herein was supported by Project MAC and the 
Artificial Intelligence Laboratory, M.I.T. research programs 
sponsored by the Advanced Research Projects Agency of the 
Department of Defense under Office of Naval Research contracts 
number N0OO14-70-A-0362-0001 and -0002. 

Reproduction of this document, in whole or in part, is per- 
mitted for any purpose of the United States Government. 



LISCOM page 2 



Table of Contents 



page 

I. Introduction 3 

II. Operation - Compiling 4 

A. LISCQM's top-level functions 4 

1. COMFILE 

2. CF 

3. COMPILE 

4. CMP, CN 

B. Handy functions, global variables, 

and notes 7 

(a) Functions 7 

1. DECLARE 

2. GENPREFIX 

5. INITIALIZE 

(b) Global variables - switches t 

1. -INITIAL 

2. -SYMBOLS 

3. -GRIND 

4. -REDEF 

5. *CL0SE0, -ARITH, -MUZZLED 

6. -DEBUG 

(c) Global variables - other M 

1. UNDFUNS 

2. NEWSPECVARS 

3. GENL1ST 

4. TAGCNT 

5. FUNNAME 

(d) Notes on compiling 11 

1. Errors 

2. Generated functions 

3. F-type functions and SPECIALS 

4. Redefining system functions 

III. Operation - Formatting 14 



LISCOM pace 3 



I p Introduction 

The LISCOM version of the A.I. Group PDP/6U0) Lisp 
compiler Is a descendant of the original Greenb latt^Ne Ison 
compiler/ and Is a friendly sibling to the COMPLR version 
maintained by Jon L, White. The compiler operates in two passes 
to trans late LISP code into LAP code. The f i rst pass performs a 
general study of the S-expression function definition which Is 
to be compiled, producing as output a modified ^-expression and 
various "tables' attached to free variables. The second pass 
does the actual compilation (generation of assembly code), 
making use of the transformations performed and the Information 
gathered by the first pass. 

The LI5C0M version of the compiler is being used as a 
vehicle for the implementation of 'fast arithmetic" In LISP. 
This work is being done under the auspices of the MATHLAB 
project of the A.I. Laboratory. The early stages of the 
compiler implementation were handled by VI. Diffle, and the work 
has been contl nued by the present author. Corresponding changes 
to the LISP system were Implemented by W. A. Martin and Jon L. 
White. The Idea Is to use user declarations of fixed-point and 
floating-point variables and functions - as to the value they 
return, as well as other mechanisms more convenient in certain 
si tuatlons ( to be described at a later date), to enab le the 
open-compilation of the LISP arithmetic functions. At the 
present date, the conversion of the first pass of the compiler 
to handle fast arithmetic* has been completed. The conversion 
of the second pass Is now under way. Also, some improvement In 
the output code and many bugs in the compiler were removed as a 
joint effort of the present author and Jon L. White. 

Every attempt has been made to make the LISCOM and COMPLR 
versions compatible In the sense that a user need not make any 
changes to his file to switch from one compiler to the other. 
There are, however , differences In some of the top I eve I 
functions through whl ch the user corresponds wi th the compi lers, 
in the format of the LAP outputted, and perhaps also. In the 
speed of operation of the compilers, in the relative 
efficiencies of some of the LAP code, and In convenience to the 
user In terms of warning and error messages, etc. The usage 
conventions of the LISCOM version are described In the following 
section. The only descriptions of the usage of the COMPLR 
version available at the present date are found In A.I. Memo 
116A (PDP-6 U&B Revised), p. 5 and A.I. Memo 190 (fin Interim 
1UE Uacr's OiLLdn), Append U Z* both written by J. L. white. 
Some discussion relating to the user's Interaction with the 
compilers (e.g. relating to DECLARE) may be found in A.I. Memo 
190, p. 14 ff. A description of the actual operation of the 
compiler as of June 1969, especially the LISCOM version, written 
by W. Diffle, Is available from the present author. 
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II* Operation 

One may load In the LISCOM compiler by typing at DDT 
*LISCOMfH* or ': LISCOM §) * . Since the LISCOM version uses the 
formatting functions of the GRIND package (see A.I* Memo 190, 
Appendix F), one may use LISCOM for both compiling and 
formatting S-expr ess ions, a I though the latter is surely 
inconvenient when compared to loading In the file GRIND LISP on 
device COM, In any event* both features of LISCOM are described 
below. Let us note here, that the features described below are 
subject to change (hopefully with notice). 

Compi 1 1 ng 

A. USCOM's top-level functions; 

These functions are all FSUBRs (unless they take no 
argument in which case they happen to be SUBRs). 

1. COMPILE; COMFILE is the major function which enables 
the user to translate one or more files of LISP code (these 
files are called the 'source files', and are denoted here as 
fnl fn2, gnl gn2, etc.) into a single file of LAP code (this 
file is called the 'target file' and Is denoted here as 
tnf tnZ). 

A file to be compiled may contain function definitions (via 
DEFPROP or DEFUN) to be compiled, MACRO-def in! Lions to be 
expanded, LAP code, declarations to the compiler (via DECLARE - 
described below), comments (via COMMENT), and any other random 
5-expressions. All but function definitions via DEFPROP or 
DEFUH, MACRO-def initions, and declarations via DECLARE are 
simply passed on through to the target file 'untouched' (except 
see the discussion of the ftGRXND switch below). MACRO- 
definitions ^re expanded in Pass 1 and take priority over (i.e. 
can be used to redefine) system-defined functions. Since MAC ft 0- 
deflnitions are placed on the property list of the MACRO-name, a 
conflict will occur (of which the user will be Informed) if a 
user MACRO has the same name as a compiler function and If the 
MACRO is called from within other (or the same) MACRO* 
definitions. (The LISP system may be hacked later on to prevent 
this rare conflict from occurring by 'prefixing' a 'file name* 
to each function name). Also, noting the description of DECLARE 
below, if DECLARE is used carelessly (e.g. foolishly modifying 
global variables intended solely for the compiler's Internal 
use), trouble may ensue. No other conflicts between user names 
(for variables and functions) and compiler names can occur. 
Finally, let us note here that it [5 Intended that the compiler 
be able to compile (almost) any function that runs 
Interpret! vely and can be compiled. If any user runs into 
difficulties with the compiler, he should see the author. 
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COMPILE takes a list of n >* file-names (with device and 
sname specifications if desired - the usual default options are 
aval table) as argument. There are three special cases; n ■ 0, 
n » J, and n >■» t* 

(a) n * Qi Typing (COMPILE) to LISCOM Is completely 
analogous to typing (CMPJ) to COMPLR. This gives the user 
control over the compilation process. An example of this use, 
beginning here with the loading operation, is as follows: The 
user is talking to DDT, which has typed '** at him, 

'*'LlSC0Mfii'|' (that which the system types at the 

user is enclosed in single 
quotes. ) 

'LISCOM COMPILER (etc-)' 

(UREAD fnl fn2) (the file to be compiled) 

'(device sname) 

(UWRITE) 

'(device sname) 

(COMPILE) 

'COMPILER-LISTENING* 

R WIS (I/O switches are set as desired) 

(the compilation) 
"(func . *EXPR)* (the EXPR 'func' has been compiled) 



'FINISHED' (the compilation has been 

comp leted) 
(UFILE tnl tn2)^ 
(device sname) 

Many variations on the above are possible, e.g. outputtlng to 
the line-printer, rather than to the disk; or defining functions 
on-line and compiling them* 

The n >■ I cases are the more usual ones. Here, the 
comp I ler hand les the entl re compi la t ion process for the user, 
including the setting of I/O switches and filing (UWRITEing, 
UREADing, and UFILEIng). 

(b) n ■ U In this case, COMFILE takes a list of one 
source f i le-name 

(fnl f n? dev sname) 
as argument, and it outputs the compiled file as 

(fnl LAP dev sname), 
('dev sname' perhaps being specified by default, of course,) An 
examp le cal I is 

(COMFILE (F00 LISP)). 



LISCOM page 6 



In this case, only one source file can be translated Into a 
target file* The INITIALIZE function described below is 
relevant here, 

<c) n >» 2: In this case, COMFILE takes a list of n >• ? 
file-names as argument; the first file-name is taken to be the 
target file and the remaining n - J file-names are source flies. 
The files are picked up in lef t-to-r Ight order. In this manner, 
one or more source files may be translated Into a single target 
file. A sample call Is 

(COMFILE (OUT COMP) (F00 L1SPU (GOO LISP2 DSK JJ)). 
When n >- Z, the ^INITIAL switch (global variable) described 
below may be relevant. 

2. CF: The function CF Is available as a convenience for 
those users who need to or wish to compile the same file 
sequence twice. The file specifications made In the last call to 
COMFILE with n >■ I are preserved on the property list of the 
atom TRY, so that one need only *eval* (CF) tfor £ompl le £1 le) 
in order to repeat that call to COMFILE. 

3. COMPILE: COMPILE is used to compile or recompile 
individual functions, perhaps only in order to Investigate the 
code bei ng produced. COMPILE takes as argument a list of the 
functions (i.e. the I r names) to be compl led. I.e. 

(COMPILE fun) fun? ... funl). 
COMPILE assumes that the 5-expression definitions for the 
functions have been loaded in already by the user. In 
formatting, COMPILE uses the line-length (LINED of the device 
(console) at which the user is logged-In, as opposed to COMFILE 
which uses the line-length of the line printer (actually 80. and 
not J20.) This may be changed by the user by SETQIng LINEL to 
PAGEWIDTH. When recompiling, the function GENPREFIX discussed 
below is usefu I. 

4m CMP, CN: These functions are useful only for 
investigating the code produced by the compiler. CMP takes as 
argument a LAMBDA expression to be compiled, i.e. 

(CMP (LAMBDA . . . )), 
which is compiled as a 5UBR called TRY. I.e. CMP combines in 
one step a 

(DEFPROP TRY (LAMBDA # , .) EXPR) 
and 

(COMPILE TRY). 
CN (for Compile iiame), which takes no argument, is used to 
repeat the last call to COMPILE, through the use of the global 
variable FUUNAME, mentioned below. 



L1SC0H page 7 



B. Handy functions, global variables, and notes: 

The following is a description of functions and global 
variables available In the compiler to aid In the compilation 
process: 

(a) Functions 

1. DECLARE: DECLARE, an FSUBR, Is an all-purpose function 
used In handling declarations of variables (via the functions 
SPECIAL and UNSPECIAL) and functions (via *FEXPR and *LEXPR) as 
well as in causing evaluations to take place Immediately* 
Indeed, 

DECLARE [expr.J - KAPC [{FUNCTION EVAL) (CDR expr.}]. 
(Thus, one need not use DECLARE upon having loaded in the 
compiler, before initiating the compilation process.) DECLARE 
will also enable the user to Inform the compiler as to how he 
wishes 'fast arithmetic' to be done, when such Is available - a 
full description will be given at that time. DECLARE is treated 
by the LISP interpreter just as Is COMMENT; however. In the 
compiler it takes effect whether used at the top level or In a 
function definition. DECLARE or an alternative must be used to 
i nform the compl ler 

(1) via the compiler function SPECIAL of variables which 
appear free in some function(s) in the file or of those which 
the user would like to refer to by name later on. The compiler 
and the user may access these variables via the 'SPECIAL cell' 
on their property list. Much will be said of the former use In 
later sections. The function UNSPECIAL Is used to remove the 
SPECIAL declaration. 

(2) via the compiler functions *FEXPR and *LEXPR, 
respectively, of FEXPRs and LEXPRs (I.e. EXPRs with atomic, non- 
NIL LAMBDA-IIsts) which are called within function definitions 
before they themselves appear (are defined) in the file, (the 
default option for such 'undefined' functions Is that they are 
of EXPR-type, and an error message will be printed out If this 
Is not done). If Indeed they appear there at all. 

DECLARE Is also used in SETQing the 'user-accessible' global 
variables described below. Thus, a sample call Is 

(DECLARE (SPECIAL varJ varZ) (*F£XPR funf) (SETQ *GRIND 5) 
(GENPREFIX H)K 
(SPECIAL, UNSPECIAL, *EXPR, *FEXPR, *LEXPR, and GENPREFIX are 
all FSUBRs defined by the compiler.) 

2. GENPREFIX; GENPREFIX Is useful when recompiling 
individual functions to be placed in a file alongside other LAP- 
code or In compiling several files at different times which are 
later to be assembled into one system. GENPREFIX Is used to 
avoid conflicts between tags and between GENSYMs (generated 
symbols) which are used by the compiler for generated functions 
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(sec the 'Notes* section below). (Tags are local to the LAP 
function in which they appear, but only one occurrence of each 
tag may appear In a DDT symbol table). The syntax is 

(GENPREFIX atom) 
and the atom, e.g. BAR, is used (I) to prefix a GENSYM, e.g. 
converting G010S to 6AROI05 in the case of generated function 
names; and (?) as the prefix to an integer (counter) TAGCNT tn 
the case of tags. See the discussion of the global variables 
GENLIST and TAGCHT below. A one-character atom Is usually used, 
and indeed the generated atom (DAROfflS here) may not have more 
than 6 characters if ft Is to be placed In a DDT symbol table. 
GENPREFIX also resets TAGCNT (see later) to 0. (It is hoped 
that some day functions associated with GENSYMming will be added 
to the LISP system to replace the need for GENPREFIX as used for 
generated functions. } 

3. INITIALIZE: INITIALIZE, a SUBR, is useful when 
compiling more than one file with a single loading of the 
compiler. INITIALIZE takes as argument 1/ 2, or 3 which 
indicates Its mode: If arg » J, INITIALIZE removes all SPECIALS 
from the OBLIST. This Is obviously a less efficient alternative 
to declaring all of one's SPECIAL variables UNSPECIAL at the end 
of the file. If arg = 2, INITIALIZE removes all *EXPR, *FEXPR, 
*LEXPR, and MACRO properties from the OBLIST, except for those 
*EXPR flags used by the compiler. If arg = 3, INITIALIZE takes 
both of the actions described above under args J and 2. Thus 
INITIALIZE can be used to obtain a clean environment for 
compiling the next file, without the necessity of reloading the 
compiler. When using COMPILE with n > 2, INITI ALIZCEJat Ion Is 
accomplished through the setting of the ^INITIAL switch, 
described below. 



(b) Global variables - switches: 

Some of the user-accessible global variables In the 
compiler are switches which may be set (e.g. via DECLARE) to T 
or NIL, or to an integer, as the case may be. To Indicate which 
global variables are switches, * Is used as the first character 
of the I r names. 

I. ^INITIAL: As mentioned above, when using COMPILE with 
n > Z § INITIALIZE may be called between each pair of files 
inputted for compilation by simply setting ^-INITIAL 
appropriately. ^INITIAL Is the argument to INITIALIZE, and the 
actions caused by setting ftlNITIAL to J, 2, or 3 were described 
above. The default setting is 0, In which case INITIALIZE Is 
not called. 
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*. ^SYMBOLS: Setting ^SYMBOLS to T causes (SYMBOLS T) 
fol lowed by a tag to be i nserted Into the LAP-code immediate ly 
after the (LAP funname type) pseudo-instruction for each 
function then compiled. The tag is useful in cases where two 
function names begin with the same 6 characters, since these 
cannot be differentiated within the DDT symbol table. For an 
explanation of (SYMBOLS T-or-NIL) see A.I. Memo 190, p. 1-5, The 
default setting of ^SYMBOLS Is NIL. 

3* *GRIND: Any S-expression (including MACRO-def In! ttons) 
In the source file that is not a function definition is output 
'as Is' (as described below) Into the target file. (Even 
DECLARES are output, so that if the user wishes to investigate 
his LAP code, he can easily check out the compiling environment 
as to SPECIALS, UNSPECIALs, etc.) *GRIND elves the user control 
over the manner in which both the random S-expresslons mentioned 
above and the LAP-code Is output, as follows: 

*GRIND « (the default setting): everything Is 

formatted ('ground'). 

= It only the LAP-code is ground. 

* 2: only the random S-express Ions are ground. 

■ 3: nothing is ground. 
Furthermore, If *GRIND ■ or I, the compiler outputs a form- 
feed after every 56 lines (or so - if *GRIND * I); if '-GRIND = 2 
or 3, the compiler outputs a form-feed after the LAP-code for 
each compiled function. Whereas formatting makes for much more 
aesthetic and readable output, it Is time-consuming and the user 
may prefer not to grind out e.g. his LAP-code. 

4. *REDEF: When set to T, *REDEF tells the user about 
functions which are defined more than once In the source files. 
This may be useful when compiling more than one source file with 
one loading of the compiler, with che Intention of assembling 
these files into one file or system. Users who intend to 
compile the same file more than once with one compiler loading, 
e.g. to take advantage of the compiler's declaring as SPECIAL 
undeclared free variables, should not have *RE0EF set to T on 
the first go-round. The default setting of *RED£F is NIL. 

5. *CLOSED, *ARITH, *MUEZLED: These switches have to do 
with fast-arithmetic compiling, and hence, are not yet of 
interest. It should be pointed out, though, that setting ^CLOSED 
to T, which In fact Is Its current default setting, causes the 
compiler not to attempt to do any fast-arithmetic compiling, 
which Is now the Intention. 
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o» flDEBUG: As the compiler Is loquacious In Its error and 
warning messages (see section (d) I. below), several LISP users 
have used the compiler for debugging purposes - seeking out 
typing errors, etc. For this reason, a special faster debugging 
mode, which Is entered by setting *DEBUG to T, has been added to 
the compiler. In which no LAP code Is generated, no output file 
is opened, and In fact, the compiler does not go through Its 
second pass at all. The lists UHDFUNS and NEWSPECVARS (see 
below) ar^ still maintained. The only warning message which Is 
not issued Is that for undefined GO tags {see below). One may 
use C0MF1LE In the manner described above* (For n >° Z, the 
target file should be NIL). The default setting of *DEBUG Is 
NIL. 
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(c) Global variables - other: 

T. UNDFUH5: Upon completing the compilation for each call 
to COMPILE/ the compiler prints out the elements of the list 
UNDFUNS. These are the names of user functions which though 
called within the source file(s), were not defined there. The 
functions appear In UNDFUNS In the order of their first call. 
The user can ask for this list to be printed again (or for the 
first time Jn the case of COMPILE) by evading UNDFUNS. 

2. NEWSPECVARS: NEWSPECVARS Is a list of all those 
variables seen since the last call to COMPILE or COMPILE which 
appeared free In some function but were not declared SPECIAL* 
These variables are made SPECIAL by the compiler. To have this 
list printed out, the user may eval NEWSPECVARS. 

3. GENLIST: Eval ling (GENPREFIX atom) as discussed above, 
say atom ■ BAR, sets GENLIST to the list (BAR). Thus, the 
same result can be had by setting GENLIST accordingly, except 
that GENPREFIX also resets TAGCNT to fl. The default setting of 
GENLIST Is (G). 

4. TAGCNT: Tags generated by the compiler are obtained by 
(MAKNAM (APPEND GENLIST 

(EXPLODE (SETQ TAGCNT (ADD! TAGCNT))))). 
Upon loading in the compiler, TAGCNT Is set to 0. The user may 
set TAGCNT to some positive Integer If he wishes. 

5. FUNNAME: FUNNAME Is set by COMPILE and COMPILE to the 
name of the current function being compi led, or to the last such 
function if the compi ler has just completed compi 1 Ing a 
function. Thus, if an error occurs while compiling, evalllng 
FUNNAME enables the user to determine the name of the function 
being compi led. 



(d) Notes on compiling 




rareiy it ever occur. 

In the case of (?) or {£), the compiler enters a read-ev 
print loop which is useful in debugging the compiler or In 
investigating further the existing state of affairs. To exit 



il- 
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from this loop, the user usually types Fg or IZ; of course, with 
the Intention of notifying the author in case of a compiler 
error. The user may also wish to type $P_ or $X_ {$ ■ <alt. 
mode>, _ ■ <space>) to proceed. In the case of (?) compiler 
errors. In which case the compiler prints out *BREAK* followed 
by the error message, typing either $P_ or $X_will cause the 
compiler to recommence compiling with the next function [n the 
file. (In this case only/ the compiler may have output some 
spurious LAP-code.) In the case of (2) data-errors, the 
compiler prints out either ftllRDATAERR* or *RDATAERR* followed by 
the error message. In the case of *NRDATAERR* or 'non- 
recoverable data error', typing $P_ or JX_ again causes the 
compiler to go on to the next function. In the case of 
*RDATAERR* or 'recoverable data error', typing $P_ causes the 
compiler to continue compiling the same function, perhaps after 
making some reasonable adjustment If necessary; while typing $X_ 
again causes the compiler to go on to the next function. The 
intention is to give the user the option of continuing with the 
same function with the possibility that the compiler will 
discover more data-errors therein; or indeed, the compiler may 
correct the error, as described below. The user may In any 
event decide to recompile the function or the file later on. At 
present, there are only four cases of 'recoverable data-errors': 

U) The compiler encounters an FEXPR or IEXPR definition, 
having previously compiled the function as an EXPR. Typing $P_ 
will cause the compiler to continue compiling, taking the 
function to have F-type or L-type, respectively, from now on. 

(Z) The user has a MACRO-def i ni tion with the same name as a 
compiler function. The user will lose only In the situation 
described above (i.e. the MACRO Is called within other (or the 
same) MACRO-def Ini tions. ) If this Is not the case, the user may 
type $P_ 4 and the compiler will continue, making certain that a 
conf Met will not occur. 

(3) The user calls a system function with the wrong number of 
arguments. The user may type $P_ , causing the compiler to 
continue as follows: If he called the function with too few 
arguments, the compiler appends HlLs for each of the remaining 
arguments. If he called the function with too many arguments, 
the compiler makes no change in the case of closed-compiled 
functions. The more commonly used open-compiled functions pull 
off only as many arguments as they need. Later, the user may 
wish to edit the LAP-code for this function or recompile It. 

14) A RETURN is used not In the context of a PROG. Typing $P_ 
will cause the compiler to strip off the RETURN, I.e. convert 
(RETURN arg) to arg, and continue. 

Other possible errors In user code may simply cause the 
compiler to print out a warning message and go on. This does 
not mean that these situations are not really errors. For 
example, the compiler nay complain that It has encountered a 
free variable which has not been declared, which it then makes 



LISCOM page J 3 



SPECIAL. If this variable has been used bound In previous 
functions and the user Intends for these occurrences to mean the 
same variable/ then a ml scompl latlon has occurred. Warning 
messages are also given In case of unused PROG or LAMBDA 
variables * bound variables which are not declared SPECIAL and 
which are not evaluated within that PROG or LAMBDA; undefined GO 
tagS/ in which case the compiler simply outputs a JR5T (jump) to 
the end of the LAP-code for the PROG; etc. These may all 
signify errors. 

2. There are two circumstances which cause the compiler to 
compile code out of context. I.e. to extract LISP code from a 
function definition and to compile It as a generated function: 

(1) Lambda funargs: any occurrence of 

(FUNCTION (LAMBDA . . .J) 
in code causes the LAMBDA expression to be compiled as a 
separate function. 

(2) Any call to ERRSET of the form 

(ERRSET arg/ argZ) 
or 

(ERRSET argH 
in which argJ is neither an atom nor a list of a single atom 
(I.e. a function ca 1 1 wi th no arguments) causes arg I to be 
compiled as a separate function of the form 

(LAMBDA NIL argf). 
The latter circumstance as a cause for compilation out of 
context will probably be eliminated In the near future. 

Clearly, any variables which appear free In these LAMBDA 
expressions (perhaps as a result of their being compiled out of 
context) must be declared SPECIAL. 

3. Any variables appearing In arguments to F-type 
functions which are to be evaluated (e.g. the latter arguments 
to ARRAY) must be declared SPECIAL. Unfortunately/ here the 
compiler does no checking for the user. Hence/ the user will 
lose if he does not heed this warning. Also/ the user must 
remember to declare as SPECIAL any free variables appearing In 
functional position/ or the compiler will take them to be 
undefined functions and compile then as SUBRs. 

4. In his LISP code to be compiled/ the user may redefine 
a LISP system function as a MACRO but not as an EXPR or EEXPR. 
If the user wishes the latter/ e.g. to redefine SUBST vta an 
EXPR/ he may do the following instead: 

(DEFUN SUBST MACRO (X) (CONS 'SUBSU (CDR X)>) 
(DEFUN SUBSTI EXPR . . .) . 
(The atom EXPR' of course Is unnecessary. ) 
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III. Formatting 

There are two functions aval lable in the compi ler for 
formatting: FORMFILE, analogous to COMPILE, for formatting a 
file and FORMAT, analogous to COMPILE, for formatting function 
definitions. Except for their obviously different purpose, the 
syntax and semantics for these functions Is slml lar to that for 
COMPILE and COMPILE, respectively, except that (I) at present, 
FORMFILE has no n ■ mode; (?) when n ■ J, the assumption Is 
that the user when evalling (FORMFILE tfn) fn?)) wishes to 
clobber the source file, i.e. wishes to give the target file the 
same name as the source file. 



Please notify the author in case of compiler bugs or If you 
have other comments to nake. 



